Peer-to-Peer Overview

 

 

This chapter provides an overview of the Peer-to-Peer (P2P) in-line services.

The System Administration Guide provides basic system configuration information, and the product administration guides provide procedures to configure basic functionality of core network service. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.

This chapter covers the following topics:

 

•	Supported Platforms and Products

•

Licenses

•	P2P Overview

•	How P2P Works

 

Supported Platforms and Products

P2P is an in-line service supported on ASR 5000 running 3GPP, 3GPP2, LTE and WiMAX core network services.

 

Licenses

P2P is a licensed feature, requiring the [600-00-7605] Peer-to-Peer Detection Bundle 1k Sessions license. For information on core network licenses and other requirements, please contact your local sales representative.

 

For information on license requirements for any customer-specific features, please contact your local sales/service representative.

Important: For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration and Configuration Guide.

 

P2P Overview

P2P is a term used in two slightly different contexts. At a functional level, it means protocols that interact in a peering manner, in contrast to client-server manner. There is no clear differentiation between the function of one node or another. Any node can function as a client, a server, or both—a protocol may not clearly differentiate between the two. For example, peering exchanges may simultaneously include client and server functionality, sending and receiving information. P2P utilizes the Enhanced Charging Service (ECS) functionality. For information about ECS, refer to the Enhanced Charging Services Administration Guide

Detecting P2P protocols requires recognizing, in real time, some uniquely identifying characteristic of the protocols. Typical packet classification only requires information uniquely typed in the packet header of packets of the stream(s) running the particular protocol to be identified. In fact, many P2P protocols can be detected by simple packet header inspection. However, some P2P protocols are different, preventing detection in the traditional manner. This is designed into some P2P protocols to purposely avoid detection. The creators of these protocols purposely do not publish specifications. A small class of P2P protocols is stealthier and more challenging to detect. For some protocols, no set of fixed markers can be identified with confidence as unique to the protocol.

Operators care about P2P traffic because of the behavior of some P2P applications (for example, Bittorrent, Skype, and eDonkey). Most P2P applications can hog the network bandwidth such that 20% P2P users can generate as much traffic as generated by the rest 80% non-P2P users. This can result into a situation where non-P2P users may not get enough network bandwidth for their legitimate use because of excess usage of bandwidth by the P2P users. Network operators need to have dynamic network bandwidth / traffic management functions in place to ensure fair distributions of the network bandwidth among all the users. And this would include identifying P2P traffic in the network and applying appropriate controlling functions to the same (for example, content-based premium billing, QoS modifications, and other similar treatments).

The P2P detection technology makes use of innovative and highly accurate protocol behavioral detection techniques. This P2P solution can detect the following protocols and their capabilities in real time:

 

•	AppleJuice

•

Ares

•	BitTorrent

•	File downloading and uploading (plain / encrypted BitTorrent)

•	Un-encrypted, plain-encrypted, and RC4-encrypted file transfer

•

Ddlink

•	DirectConnect

•

eDonkey

•	File uploading and downloading (plain / encrypted eDonkey)

•

FastTrack

•

Feidian

•

FileTopia

•

Fring

•

Gadu-Gadu

•

Gnutella

•	Google Talk

•

Voice

•

Non-voice

•	Half-Life 2

•	HamachiVPN

•

iMesh

•

IRC

•

iSkoot

•

Jabber

•

Manolito

•

MSN

•

Voice

•

Non Voice

•

Mute

•

ooVoo

•

Orb

•	Oscar / AoL

•

Voice

•

Non Voice

•

Pando

•

PoPo

•

PPLive

•

PPStream

•

QQ

•

QQLive

•

Skinny

•

Skype

•

Voice

•

Non Voice

•

Slingbox

•

SopCast

•

SoulSeek

•

Steam

•

TVAnts

•

TVUPlayer

•

UUSee

•

VPN-X

•

VTun

•

WinMX

•

Winny

•	World of Warcraft

•

Xbox

•

Yahoo

•

Voice

•

Non Voice

•

Zattoo

When P2P protocols are detected, statistics reporting and postpaid charging policy are supported. Per-protocol statistics via bulkstats and via report records including:

 

•	UDR types: Summarizing data usage for a given content type

•	EDR types: Specific to a particular event

•	e-GCDRs: Specific to 3GPP

Upon detection of a P2P protocol for a particular flow, one of the following actions can be applied:

 

•	Blocking P2P traffic—blocking protocol(s) and discarding traffic

•	Bandwidth policing—limiting the bandwidth, applied per PDP context per P2P application type

•	Flow policing—limiting the number of simultaneous P2P flows

•	QoS support—including policing

•	TOS marking—applied per P2P protocol type

•	Prepaid and postpaid charging support for the following P2P protocols:

•	AppleJuice

•

Ares

•	Battlefield

•	BitTorrent

•	DirectConnect

•

eDonkey

•

FastTrack

•

Filetopia

•

Fring

•

Gadu-Gadu

•

Gnutella

•	Google Talk

•

iMesh

•

IRC

•

iSkoot

•

Jabber

•

Manolito

•	MSN voice/non-voice

•

Mute

•

ooVoo

•

Orb

•

Oscar

•

Pando

•

PoPo

•

PPLive

•

PPStream

•

QQ

•

QQLive

•	Skype voice/non-voice

•

Slingbox

•

SopCast

•

SoulSeek

•

UUSee

•

Winny

•	Yahoo voice/non-voice

•

Zattoo

•	Prepaid and postpaid P2P content-based billing

•	Statistics reporting—analyzing per-protocol statistics using bulkstats

 

Dynamic Signature Updates

P2P traffic detection is tricky because most of the P2P protocol details are proprietary, and the protocol characteristics change frequently. As these P2P standards are proprietary, there is a tight coupling between the peers too (all the peers need to understand the protocols). Since P2P detection depends heavily on the known traffic characteristics the detection can suffer if the P2P protocol changes, if some existing traffic characteristics were not known (new use case scenarios), if one P2P traffic characteristic matches with another P2P traffic (false positives), and if there are flaws (bugs) in the detection logic. Whenever such degradation in P2P detection logic is identified, the P2P detection engine needs to be fine tuned or enhanced further to improve the detection accuracy.

In the earlier releases, the P2P detection logic was part of the chassis software load (ASR 5000 software), to continue to detect new traffic patterns based on the changing traffic characteristics, operators needed to upgrade the complete software with the updated logic.

This release supports dynamic upgrades of the P2P detection logic (signatures) alone on an active ASR 5000 without warranting a full software upgrade, and hence without a software restart or reboot. This is implemented through signature files.

Important: This release supports dynamic upgrades of detection logic for the following P2P protocols: Bittorrent, DirectConnect, eDonkey, Gnutella, Skype, and Yahoo.

Important: Dynamic signature updates may not work in all situations, and software updates may be required to update the detection logic in use on a system.

In an initial software build, all the detection logic is embedded in the code. If in a subsequent software build, there are updates to the detection logic, the changes are made available as a P2P signature file. If the initial build supports the Dynamic Signature Updates feature, this signature file can be loaded on the system to update the detection capability.

In case a P2P signature file is already available for a software build, when the configuration file is loaded on the system, it will take the lastest version. If a different P2P signature file is manually loaded on that system, every time the system reboots, it will load the default version.

A P2P signature file can support upgrade for multiple P2P protocols that are enabled for dynamic upgrade. Operators can selectively upgrade the detection for specific protocol(s). Patches can be rolled down with out any negative impact to the system. If an incorrect signature file is loaded by mistake, the version information in signature file will not match the current protocol detection version and the system will not be affected.

The signature files are provided on a need basis, or periodically whenever a new P2P detection software version is integrated with the software. A signature file can contain the rules for several protocols. The P2P signature file is packaged as a delivery kit for release. For more information, contact your local sales representative.

 

P2P Protocol Detection Software Versions

Every released signature file has a file version. This version number is used to determine which file is the latest and newest to load during upgrade or reboot. On the boxer, the signature file version and the syntax is validated, in case of failure, the signatures will not be loaded into memory.

 

Enabling and Disabling P2P Dynamic Signature Updates

The P2P Dynamic Signature Update feature can be enabled and disabled from the CLI.

Disabling the P2P Dynamic Update feature instructs the system not to load and apply the signature files. An already loaded signature file can be unloaded (removed) from the system’s memory too.

CLI show commands can be used to view details of loaded signature file, and the P2P as well as the individual protocol detection software versions.

 

Loading and Unloading P2P Signature File

 

Loading Signature File

If a P2P signature file is already available for a software build, the system loads the file from the default location, which is “/usr/lib/p2p-rules.xml”.

Operators can load P2P signature files present in the system’s Flash directory from the CLI. A P2P signature file loaded from the Flash directory must always be available in the Flash directory. In this case, based on the signature files’ version numbers, the P2P engine loads the latest file available between the default file and the new file specified in the configuration.

Loading of rules is a two-stage process. First, from the signature file the signatures are loaded to all the Session Managers (SessMgrs). Once all the SessMgrs are able to parse the signatures successfully, the signatures are activated. If any SessMgr reports failure in parsing the signatures, the activation will not be done. A deactivate message will be sent to the managers so that any SessMgrs that successfully parsed the signatures will unload them.

When, on a system, the signature file containing the rules are loaded for the first time, new calls generated after loading the rules would use these rules.

There can only be a maximum of two signature files loaded on the system’s memory at any point of time. If a loaded signature file has active calls, and the operator loads a newer version of the rule file, the older file will be removed from the memory once all the calls referring to it have ended. All calls generated after loading the new file will use the newer file.

Considering the memory used for loading the signature files, the number of active versions that can be loaded is restricted to two. Suppose we currently have a patch D1 loaded and running, and have an update D2. After loading D2 in memory, D1 will still be active in memory because there may be some call lines using this version. Loading a new patch D3 has to wait till D1 is removed from the memory.

Important: In case of session recovery, when subscriber call is recovered, it will always use the active version of the P2P signature file available in the memory.

 

Unloading Signature File

When a signature file is unloaded from the CLI, the SessCtrl sends request to all the SessMgrs to unload the file from memory. The SessMgr maintains the reference count for the version loaded into the memory. If the reference count is zero, the rules are deleted from the memory. If there are some sessions using the version to be unloaded, the version is marked for unloading. When there are no references to the version, it is deleted from the memory.

 

How P2P Works

P2P interfaces to a PCRF Diameter Gx interface to accept policy ACLs and rulebases from a PDF. P2P supports real-time dynamic policy updates during a subscriber session. This includes modifying the subscriber’s policy rules during an active session by means of ACL name and Rulebase name.

 

In Rel. 7 Gx interface, a Charging Rulebase will be treated as a group of ruledefs. A group of ruledefs enables grouping rules into categories, so that charging systems can base the charging policy on the category. When a request contains names of several Charging Rulebases, groups of ruledefs of the corresponding names are activated. For P2P rules to work in the group of ruledefs, P2P detection has to be enabled in the rulebase statically.

Static policy is supported initially. A default subscriber profile is assumed and can be overwritten on the gateway. Per-subscriber static policy is pulled by the gateway from the AAA service at subscriber authentication.

The following figure illustrates how packets travel through the system using P2P detection. The packets are investigated and then handled appropriately using ruledefs for charging.

Overview of Packet Processing in ECSv2

 

Advantages of P2P Processing Before DPI

 

•	Some protocols like BitTorrent and Orb use HTTP traffic for initial setup. If P2P analysis is done after HTTP, it is possible that these protocols may go undetected.

•	Protocols like Skype use well known ports (like 80 & 443). In these scenarios, the HTTP engine reports these as invalid packets. For protocol detection, it is desirable to have P2P detection before Deep Packet Inspection (DPI).

•	Stateless detection of protocols based on signature will be easier when the P2P analysis is done before DPI.

 

P2P Session Recovery

Intra-chassis session recovery is coupled with SessMgr recovery procedures.

 

Intra-chassis session recovery support is achieved by mirroring the SessMgr and AAAMgr processes. The SessMgrs are paired one-to-one with the AAAMgrs. The SessMgr sends checkpointed session information to the AAAMgr. ACS recovery is accomplished using this checkpointed information.

Important: In order for session recovery to work there should be at least four packet processing cards (PSCs/PSC2s), one standby and three active. Per active CPU with active SessMgrs, there is one standby SessMgr, and on the standby CPU, the same number of standby SessMgrs as the active SessMgrs in the active CPU.

There are two modes of session recovery, one from task failure and another on failure of CPU or PSC/PSC2.

 

Recovery from Task Failure

When a SessMgr failure occurs, recovery is performed using the mirrored “standby-mode” SessMgr task running on the active packet processing card. The “standby-mode” task is renamed, made active, and is then populated using checkpointed session information from the AAAMgr task. A new “standby-mode” SessMgr is created.

 

Recovery from CPU or PSC/PSC2 Failure

When a packet processing card hardware failure occurs, or when a planned packet processing card migration fails, the standby packet processing card is made active and the “standby-mode” SessMgr and AAAMgr tasks on the newly activated packet processing card perform session recovery.

 

Limitations

This section lists the limitations of P2P detection in this release.

 

Skype

 

•

The Skype detection cannot detect traffic of most of the third-party plug-ins. The plug-ins use Skype only for marketing and presentation purposes such as opening a window within a Skype window or modifying the main Skype window with buttons or sounds. These plug-ins do NOT use the Skype protocol to transfer data over the network.

•	Other than Skype Voice, all detected Skype traffic is marked as Skype. Distinctions between different data types within Skype (i.e. text chat, file transfer, and so on) cannot be made.

•	Skype voice detection may not be accurate if it happens with other traffic (file transfer, video, etc.) on the same flow.

 

eDonkey

 

•

The eDonkey client eMule supports a protocol named Kademlia. This protocol is an implementation of a DHT (Distributed Hash Table). Kademlia is only used for searching new peers which have the file the user wants to download. The download itself uses the eDonkey protocol. However, the Kademlia protocol is not detected as eDonkey.

•	The eDonkey client eMule supports a text chat that is not detected as eDonkey.

 

Yahoo

Yahoo! HTTP downloads for yahoo games, images and ads that come during yahoo messenger startup are not detected as Yahoo!. If configured, these can be passed on to the HTTP analyzer for HTTP Deep Packet Inspection.

 

MSN

MSN HTTP downloads such as MSN Games and MSN Applications are not detected. Traffic from these MSN applications use a different protocol for their traffic.

 

BitTorrent

 

•

Some clients (like Azureus 3.0) provide an advanced user interface which can include an embedded web browser. These are not detected as BitTorrent. Also other features like chat or instant messaging are not detected as BitTorrent. These features are client specific and not related to the BitTorrent protocol.

•	Certain clients also display advertisements. These images are downloaded through plain HTTP and are not detected as BitTorrent.

 

Jabber

 

•	Most clients that use Jabber for IM offer other services like Voice Call or File Transfer. These services are not detected as Jabber.

•	Jabber with SSL encryption cannot be detected, because it uses SSL.

 

Gnutella / Morpheus

 

•	Some of the clients that use Gnutella protocol for file sharing can also use other file sharing protocols. The part of traffic that follows Gnutella Protocol will only be detected as Gnutella.

•

Client specific patterns which are not part of the Gnutella Protocol will not be detected as Gnutella. UDP contributes to about 20-30 % of most Gnutella clients. Detection is based on some strange patterns in the first packet of these UDP flows. Untested Gnutella clients may have more strange patterns, causing drop in the detection %.

•	The Morpheus Client creates a lot of TCP flows, without any string pattern in the application header. These flows are not currently detected.

 

Winny

The Winny client also supports bbs. This is currently not detected.

 

FastTrack

SSL packets and HTTP packets from the Kazaa client is not detected. Only data transfer is detected.

 

Gadu-Gadu

Radio traffic passes through HTTP and is not detected.

 

Other Limitations

 

•

Most of the heuristic analysis for a subscriber is stateful and depends on building an internal state based on certain patterns seen by the analyzer. Patterns occur over multiple packets in a single flow and over multiple flows for a subscriber. If the system loses the state (due to a task failure for example), then the detection can fail for the affected subscribers/flows after recovery.

Most P2P protocols emit these patterns regularly (sometimes as early as the next flow created by the application). When the system sees the pattern again, it re-learns the subscriber state and starts detecting the protocol.

•	In this release, P2P rules cannot be combined with UDP and TCP rules in one ruledef.

 

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883